%!TEX root = main.tex
\section{Introduction}
This \paper presents NDNS (DNS for Named Data Networking) which is designed to
 be scalable, universal and authenticated data storage in NDN network and allow data retrieval with minimum information.
 NDNS is also suppose to be infrastructure component candidate in NDN network.
The design goals include:
1) scalability, NDNS is capable to support requests at internet-scale;
2) universality, NDNS has no restriction on the format or content of stored data;
3) origin authentication, data in NDNS is truly produced by the name owner.

NDNS inherits the hierarchical structure from traditional DNS in order to scale the lookup for retrieval.
Name servers are hierarchically structured.
Servers of each zone contains pointer to the servers of its children zones.
NDNS stores application generated Data packet as is without examining its content field in order to achieve universality goal.
It's the name owner who fully decides the format and the content.
In order to achieve the authentication goal,
NDNS adopts hierarchical trust model,
and stores the certificates of all the keys used to sign Data in NDNS.
End users constructs authentication chain from trust anchor to any Data store in NDNS by iteratively fetching certificates from NDNS.

%\cite{Ghodsi:2011aa} proposes ``real world identity'' (publisher),
%which is define to be the real world entity who is the principal of data.
%In NDNS, producer is more specific to be the holder of a pair of asymmetric keys.
%\footnote{A publisher must own at least one pair of asymmetric keys.}

%The immediate benefits of storing publishers' certificate in NDNS include:
%1) clarify the namespace allocation, and avoid undesirable namespace clashes or conflicts for applications;
%2) provide an optional hierarchical trust model and its the necessary certificate information to all NDN-based applications.

NDNS provides query and update interface to the public.
NDNS allows two ways of data accessing:
1) fetch the data from NDNS via its name directly;
2) discover data stored in NDNS via stylized mechanism with very limited prior knowledge.
As to update, only authorized identity is allowed to update stored data dynamically.
%What is more, zone synchronization mechanism is also design to synchronize their database among name servers belonging to same zone.

%In NDN, publisher owns a namespace by holding the corresponding certificate issued by the publisher of parent namespace.
%NDNS maintains a hierarchical name-tree according NDN applications namespace.

NDNS is also designed to be infrastructure component in NDNS network,
as the role DNS plays in IP network,
due to the urgent challenges from NDN research and deployment:
e.g.,
1) to avoid unexpected namespace clashes or conflicts and defend namespace spoofing;
2) to distribute public keys and certificates for cryptography support;
3) to solve the routing scalability with proposal like LINK and Map-and-EnCap\cite{maen2015}.
Including but not limited to the above immediate use cases, NDNS can be widely used for other goals, depending on applications intentions.

Design wise, NDNS is highly inspired by DNS, such as hierarchical structure, caching, domain and zone, recursive and iterative queries, hierarchical trust model, etc.
It is worth noting that the design in this \paper is an extension and improvement of the one proposed in \cite{afanasyev2013addressing}.
The fundamental ideas and concepts remain working,
but this work highlights the scalability, universality and original authentication goals, and improves its design with different implements from the bottom,
including the database schema, packet format, the way name server handle Update message, terminologies and application tags, etc.

The rest of this \paper is organized as follows:
The following section compares NDNS and DNS together with its following work in details.
Section \ref{sec:design} presents the NDNS design on naming, query, update and trust model.
Section \ref{sec:imp} gives the implementation including database schema and packet format.
Section \ref{sec:manage} describes the management of NDNS.
Section \ref{sec:deploy} presents NDNS deployment in NDN testbed and its use cases.
And Section \ref{sec:summary} summarizes the \paper at last.
